Contracting Workflows and Protocol Patterns

Inter-organizational business processes often involve contracting. ICT solutions for contracting processes must offer high flexibility in changing the structure of the contracting process. This can be achieved by ‘process-aware’ software components which are configured by an explicit model of the contracting process: the contracting workflow. However, the design of a contracting workflow from scratch is a complex task. We propose a solution in which contracting workflows are composed from standard building blocks and show that protocol patterns for business transaction protocols are a necessity for making these standard building blocks available. Finally, we propose a number of protocol patterns for the negotiation phase in a transaction. 1 Electronic Contracting Inter-organizational business processes often involve contracting. When one organization buys something from another organization, a distinction between ‘products’ and ‘services’ is often made. Although products and services differ in many ways, the question is whether these differences are relevant from the perspective of the contracting process. This question is answered by for instance Normann and Ramirez [7], who state “whether customers buy a ‘product’ or a ‘service’, they really buy access to resources”. Hence, the authors use the term ‘offering’ to refer to both ‘product’ and ‘service’. Others, like Merz et al [6], have the same approach when they consider payments and tangible goods as services too. In this paper, we will use the term ‘service’ as a synonym for both ‘product’ and ‘service’. Service contracting involves information exchange between partners, for which electronic communication is one of the options. The term ‘electronic contracting’ was already mentioned by Lee in 1988 [5]. In this paper, we define a ‘contract’ as ‘an agreement between two parties in which the mutual obligations are stated’. Furthermore, we define the term ‘electronic contracting’ as ‘a contracting process in which the communication between parties is performed by electronic means and in which the processes at the involved parties are supported by computer applications.’ The term ‘electronic contracting’ is used for a variety of phenomena. This paper is focused on a Contracting Workflows and Protocol Patterns 153 specific part of this area, which is demarcated by the following characteristics that define a class of service contracting processes. • Loosely coupled organizations We assume a relationship between service clients and service providers where all communication is performed by exchanging structured messages, of which only the data types (static aspects) and constraints on the sequence of message types (dynamic aspects) are mutually agreed. We assume no knowledge of each others business processes for the participating organizations. • Buyer side only Electronic contracting of services always involves a buyer (client) and a seller (provider). Although these parties communicate via a common message protocol, they execute different processes. This paper focuses on the contracting workflow executed by the buyer (service client). The seller (service provider) is treated as a black box, of which only the external interface (transaction protocol) is known. • Multiple required services, Multiple available providers A contracting process is performed for a business case in the enterprise information system. This paper focuses on the more complex contracting processes where each business case requires N different services to be contracted, for which M different service providers are available. • Dependencies between services We assume dependencies between required services that define the order in which services must be contracted. For example, service B must be contracted when service A has been completed (sequential relation). Or, service B must be contracted only if service A could not be contracted (alternative relation). Apart from a demarcation of the class of processes under consideration, we further limit the scope of this paper by focusing on the dynamic aspects of contracting processes only. Data aspects involved in contracting processes, for instance deriving the details of required services from case data or evaluating a received offer, are not in the scope of this paper. A framework for capturing the data aspects of contracting processes is given by Van Dijk [3]. 2 Modeling Technique and Approach Different approaches have been proposed for modeling of the communication between partners in a buying process. In this paper, we view contracting processes as interorganizational workflows and use Petri Nets as modeling technique. This choice is made for the following reasons. 154 A. van Dijk • Workflow management techniques based on Petri Nets have a sound theoretical basis and have been successfully applied to internal business processes like shown by Van der Aalst and Van Hee [1]. Since business processes are becoming interorganizational increasingly, the application of workflow management techniques to inter-organizational processes is an obvious choice. • Workflow management techniques have proven to be a good solution for repeating, well-structured and potentially long-running processes. The character of the demarcated class of service contracting processes has many similarities with this kind of processes. • Workflow management techniques are increasingly integrated in software tools for electronic messaging. Apparently, the market recognizes the usefulness of workflow management in combination with electronic business.